Spidel Tech Solutions, Inc. - Shall statements

Shall statements

SHALL Statements refer to the statements in a requirements document that contain the word shall.

Shall Statements are a Euphemism for Schedule.

If there are any systems engineers out there reading this, then they are already upset having read the heading above. Let me explain.

In the old days, when writing requirements, the systems engineer would encode choices about which were imperative and which were optional. The most important requirements began; “The system SHALL…" or "The system MUST…”.

If a requirement was highly desirable but not absolutely necessary then the requirement would begin; “The system SHOULD…” Finally, if a developer could squeeze it into his schedule then he would implement the extra requirements beginning with “The system MAY…”.

Well it occurred to me some years ago that with enough time most systems could be made to meet all their requirements no matter how fluffy. So why not cast the requirements in the present tense as if the system already existed. Then use the implementation schedule to determine the importance. The high priority requirements come first then the secondary requirements come later. Then change control boards determine the priority by use of the schedule. This has three benefits; First: Shall, Must, Should and May are not granular enough to specify the staging of complex systems.

Second, requirements in the present tense can easily be integrated into other documentation. Consider the utility of the following two expressions of the same requirement.

“The lawn mower SHALL cut the grass to between 3 and 6 inches.”

“The lawn mower cuts the grass to between 3 and 6 inches.”

Both are statements of intended facts. But once implemented the second can be used for other purposes such as product briefs, user guide, training guide, engineering specification etc.

Third the language is much more pleasant. Some people can get pretty heavy handed. When bandying about language with shall statements all day, well, it just gives them a reason to be mean.

"Shall" in a Systems Engineering Reality

Systems engineers like 3 numbers more than all the rest. Lets see, there is 0, 1 and infinity. Why is that? Zero and one are comfortable numbers when designing. One to one relationships are found everywhere and they are usually easy to account for. But when you are designing for 2 or 3 or any other number for that matter, you always wonder if one more will be needed. Are six cylinders enough or do I need 8 or 12? And if I have them do I need them all the time? See how this complicates life? A system engineer wants to say; you can have as many as you like. So if I were designing cars I would design the engines with bolt on cylinders so that the customer could have as many as he likes hence infinity. I remember when 2 bit processor chips came out with the ability to cascade as many as you could dream about. When designing with 1, there are a lot fewer things to worry about.

One of a systems engineer's favorite responses to questions is; it depends. Every answer is contingent on issues a systems engineer must consider. So one of the reasons I get so bent out of shape about SHALL statements is that they sound so contradictory in the context of multiple version development. Let me explain.

I was once responsible for the architecture of several loosely coupled applications that had a multi-decade life cycle. The needs list for the sum of them exceeded 10000 documented reports. I was constantly working on 4 versions of each of them.

For example; one application was due to release version 6 at the end of the quarter. So this was normal development. Version 5.5 had just been released and would have a few maintenance releases (you know the 5.5.1.2.3 stuff) associated with it. Version 5.4 was most widely distributed to the customer base and needed periodic requirements level adjustments that had to get to the field fast. Meanwhile, many of the important features would be released in version 7. Big features have long lead times and a lot of thinking and planning goes into them. So, though I did not spend a lot of time thinking about version 7, I had to have a place to write requirements about it.

So try to imagine the life of a single feature attribute across versions 5.4, 5.5, 6 and 7. In version 5.4 it must complete in 45 seconds. In version 5.5, 30 seconds, in version 6, 10 seconds and in version 7 it is merged with another feature and must complete in 15 seconds. I insisted on all versions being in one Interleaf document that could be filtered by release. so a set of requirements with their IDs looked like this;
[mmm70] Feature x SHALL complete in 45 seconds.
[mmm91] Feature x SHALL complete in 30 seconds.
[mmm120] Feature x SHALL complete in 10 seconds.
[mmm144] Feature x and y SHALL complete in 15 seconds.

when the full document was printed. It just looks stupid. Now when you add release information it makes more sense.
[mmm70](v5.4-5.5) Feature x completes in 45 seconds.
[mmm91](v5.5-6.0) Feature x completes in 30 seconds.
[mmm120](v6.0-7.0) Feature x completes in 10 seconds.
[mmm144](v7.0-) Feature x and y complete in 15 seconds.

In Interleaf, I could print the requirements introduced since release 6.0 made obsolete in release 7.0 which would display just the next to last line. This made adding, merging, withdrawing and moving features quite manageable over long tracts of time.

So, the idea of SHALL being relative, seems contradictory and I make it a habit to minimize contradictions.

Back | Next

Wikipedia Enrichment